home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 684 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.5 KB
  1. From: Torsten Scherer <itschere@techfak.uni-bielefeld.de>
  2. Subject: (another) problem with mntlib41 tfork() function
  3. Date: Sun, 5 Dec 93 15:44:36 +0100
  4. Return-Receipt-To: itschere@techfak.uni-bielefeld.de
  5.  
  6. Hi!
  7.  
  8.  It was quite often mentioned that the mintlibs tfork() function shouldn't
  9. be regarded as anything more than a hack until MiNT gets a real vfork() call,
  10. so I know I should use it with caution, but today I've strumbled into a
  11. really severe problem when writing a multi-threaded smtp sendmail clone.
  12.  
  13.  It goes like this: Each time a thread is started, memory is allocated from
  14. the calling process via pexec(5) to create a new basepage. Since this base-
  15. page isn't immediately started, the memory seems to be assigned to the
  16. calling process. This one of course forgets the adress of the threads basepage
  17. as soon as the tfork() call is left.
  18.  
  19.  So the thread comes up, works a bit and goes down again, leaving the basepage
  20. memory assigned to the caller, who doesn't know about this and therefore won't
  21. free it. To be more precicly: Each thread costs me 16K (memprot) which are lost
  22. forever.
  23.  
  24.  In general its possible to get a process' basepage by an ioctl on the procfs,
  25. but this can't be done when pwait3() reports the termination, cause the file
  26. is already removed then. So the only way to get the basepage is to ioctl
  27. directly after the tfork(), before the pwait3() and probably better before
  28. the child terminates.
  29.  
  30.  This sounds difficult and like a waste of code but was my only idea. Pity,
  31. it doesn't work correctly for very long. I guess the error is something like
  32. your Mfree() call doesn't really frees the memory cause some other child
  33. shares it and therefore it's lost again. This may not disturb you if you just
  34. want to start one or two threads, but if you want to start several dozen of
  35. them spreaded over the time the computer is running, I swear this drives you
  36. wild and/or crazy.
  37.  
  38.  The question now: When will MiNT get a real vfork?
  39.  
  40.  Hmm, or better something quick: Does the "create basepage" call already
  41. assigns a new pid to the basepage, or is it assigned later, when the basepage
  42. is run? Mightn't it be a good idea to perhaps add some Pexec() mode which does
  43. the same as the thread code from the library, but really assigns all child
  44. memory to the child, so Pterm() can free it?
  45.  
  46.  But I feel something like there isn't something like real child memory, so
  47. all memory the child may at any time allocate, is also shared by its parent.
  48. I wouldn't like this, but I wonder if that's the reason...
  49.  
  50.  Any ideas?
  51.  
  52. it's just me again, being curious...
  53. TeSche
  54.  
  55.